Skip to content

Add rationales to rule documentation#3563

Merged
sindresorhus merged 1 commit into
mainfrom
ss/add-rule-rationales
Jul 18, 2026
Merged

Add rationales to rule documentation#3563
sindresorhus merged 1 commit into
mainfrom
ss/add-rule-rationales

Conversation

@sindresorhus

@sindresorhus sindresorhus commented Jul 17, 2026

Copy link
Copy Markdown
Owner

No description provided.

@sindresorhus
sindresorhus requested a review from fregante July 17, 2026 21:36
@sindresorhus
sindresorhus merged commit aba33ff into main Jul 18, 2026
15 checks passed
@sindresorhus
sindresorhus deleted the ss/add-rule-rationales branch July 18, 2026 19:13

@fregante fregante left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I didn't get a chance to read these before. They're good for the most part.

<!-- end auto-generated rule header -->
<!-- Do not manually modify this header. Run: `npm run fix:eslint-docs` -->

Keeping empty braces together makes empty blocks and object literals easier to scan and avoids whitespace that has no meaning.

@fregante fregante Jul 18, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The style ones are a bit of a stretch. It's more like "I think it looks better" or "It's good to keep a consistent style"


Improved version of the [`no-nested-ternary`](https://eslint.org/docs/latest/rules/no-nested-ternary) ESLint rule. This rule allows cases where the nested ternary is only one level and wrapped in parens.

Nested ternaries require readers to track multiple conditions and branches at once, making them harder to read and maintain.

@fregante fregante Jul 18, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the way, I find nested ternaries acceptable at any depth, but only when they're if else if else, never if if else else. If properly formatted they're no different than actual if else if else blocks (wrap, no parens)

will open an issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants